Handling adaptive behavior in real-time systems

Applications should be able to dynamically adapt their run-time behavior to the resources available instead of relying on pre-computed scheduling and resource requirements. Under overload conditions, applicationspecific policies will be applied in order to bring the total resource requirements within the available resources. The paper describes a flexible architecture for real-time applications that can handle adaptive behavior. This architecture is based on open implementation, a design methodology for object-oriented software systems, and in particular for substrate software. This methodology recognizes that while it is beneficial to hide unnecessary implementation details, there are some design decisions that should be accessible to a system-level programmer with domain-specific knowledge. 1 Hard versus soft real-time systems An established definition of real-time systems states that the correctness of such systems not only depends on the logical result of computations, but also on the timeliness of their actions. The functional properties that characterize them are: timeliness, predictability and responsiveness. Timeliness is the ability to meet at run-time a set of time constraints. Predictability is the ability to foretell at compile-time that an implementation will not violate a set of reliability and time requirements. Responsiveness is the ability to react to external inputs in a timely and predictable manner. Practitioners in the field of real-time computer system design also traditionally distinguish between hard and soft real-time systems. Hard real-time systems are those where it is absolutely imperative that responses occur within the specified deadline. Soft real-time systems are those where response times are important but the system will still function correctly if deadlines are occasionally missed. Of course many systems will have both hard and soft real-time subsystems. In most of these systems, activities that have to occur in a timely fashion coexist with those that are not time-critical. This conventional artifactual dichotomy between hard and soft real-time reflects a misunderstanding. The situation is in most cases not so clearly binary. Hard real-time is just a special, relatively simple and restricted case, while soft real-time tasks are often just as critical as hard ones, are furthermore the general and predominant case and are often treated ad hoc. We see that usually soft realtime tasks require dynamic resource management, while hard real-time tasks require static (off-line) resource management. A different situation exists when the deadline has always to be met, but where the delivered service will depend on the available time to perform the task. The notion of quality of service (QoS) can be used in such systems. Traditional systems for hard real-time tasks do not deal with such constraints. An example of such a system is an embedded multi-media processor that has to deal with audio decoding, video decoding and service decoding. The audio decoding is not really a problem: its load is nearly constant over time. This is an example of a classic hard real-time task. The service decoding is an example of a soft real-time task: servicing the client is not especially time critical. Video decoding on the other hand has a load that is highly variable in time. It is a time critical task but the constraints are different: when the application will not meet its deadline, it is not really a problem if some frames are missing. This is not the same as missing a deadline occasionally: when not enough time is available to perform regular decoding, the application should switch to a different algorithm. A majority of the currently implemented real-time systems assume that much of the knowledge concerning the characteristics of the application and the environment is available a priori and, hence, are based on static designs. Today's and next -generation systems will have to adopt solutions that are more dynamic and flexible. This is not only because we believe that such systems will be large and complex but, more important, because they will function in environments that are dynamic while being physically distributed. In highly dynamic systems it is difficult and usually impossible to statically foresee all the possible situations that may occur. 2 The necessity to be adaptive Recent trends in networking, multi-media and mobile computing have placed new requirements on the flexibility and adaptability of real-time operating systems. It is increasingly recognized that existing realtime operating system architectures are not sufficiently flexible to meet these demands. As such there is significant interest in building more flexible, or adaptive operating systems. Instead of relying on human beings to pre-compute scheduling and resource requirements, applications should be able to dynamically adapt their run-time behavior to the resources available. Under overload conditions, application preferences and application-specific policies will be applied in order to bring the total resource requirements within available resources. This will permit chosen applications to continue executing perfectly even while other applications execute with dynamically renegotiated resource grants or are gracefully shut down, as per application preferences. When the quality of a computation can be measured, a solution of degraded but satisfactory quality given in time will often be preferred to one of optimal quality produced too late. This leads to systems which adaptively provide application-specific acceptable end-to-end quality of service (QoS) in terms of timeliness predictability despite dynamic uncertainties in the application and computing system. A main advantage of this approach is that it supports graceful degradation while still providing QoS guarantees in a resource-limited system. Assured graceful degradation may permit building smaller systems that are sized for average workloads, rather than requiring the construction of large systems sized for worst case conditions, which are anyway very difficult if not impossible to predict in a dynamic and networked environment. There is a need to facilitate the use of application-specific knowledge, policies, and optimizations. However, established real-time systems do not allow for development of policies tailored for highly dynamic environments. Programming application-specific customizations is momentarily a great pain. This was shown for example in work done on 'best-effort' transport protocols or scheduling policies for application-specified graceful adaptation to dynamic uncertainties such as overloads and disruptive network conditions. What we need are new architectures for systems that are able to adapt to and learn from their environment, and are able to respond to unexpected events. 3 Inadequacy of today's systems to cope with adaptability Decomposition and abstraction are the two principles that drive conventional software engineering in the battle to control complexity. The basic idea is simple: decompose large problems into well-defined modules that interact with one-another through interfaces that hide the details of their implementation. Together, decomposition and abstraction produce “black boxes” (see figure 1) that allow us to build larger software components from smaller components without having to know the details of how each component is implemented. The line above the black box in figure 1 represents the interface, that provides the functionality the designer of the black box has chosen to expose to the application programmer. The actual implementation is hidden inside the black box.